Oracle TimesTen In-Memory Database推奨されたプログラミングの実行

データ・ストアの同時実行性の最大化

ユーザーがシステム・リソースを使い過ぎると、他のユーザーのパフォーマンスに影響を与える可能性があります。この項では、次の推奨事項について説明します。

カーソルの即時クローズ

Oracleデータベースと同様に、TimesTenの読取り専用トランザクションは、コミットする必要がありません。ただし、読取り専用SQL問合せによって保持されたすべてのリソース（ソートに使用される一時領域など）を解放するためには、読取り専用カーソルを即時にクローズすることが重要です。

次の方法でSQLカーソルをクローズします。

ODBDの場合は、SQLFreeStmt(SQL_CLOSE)を使用します。

TTClassesの場合は、TTCmd::Close()を使用します。

JDBCの場合は、PreparedStatement.close()を使用します。

大量のDELETE文の回避

大量のDELETE文を回避するには、次の方法を検討します。

DELETE FROM文の回避

TRUNCATE TABLEの優先

DELETE FIRST句の検討

DELETE FROM文の回避

表に多数の行がある場合（10万行以上）、単一のSQL文で（単一のトランザクションで）行を削除しようとすると、問題が発生する可能性があります。第1に、この方法では処理が低速です。TimesTenでは、操作をロールバックする場合に備えて、各削除行のログが記録されます。これはディスク・バウンド操作となるため、これらのログ・レコードをすべて書き込むと、非常に時間がかかる可能性があります。

大規模な削除操作に伴う別の問題は、書込み集中型の削除トランザクションが発生すると、他のデータ・ストアの処理速度が低下することです。単一のトランザクションで数百万もの行を削除すると、完了までに数分かかる場合もあります。

一度に数百万の行を削除する際の3つ目の問題は、表をレプリケートする時に発生します。レプリケーションではコミットされたトランザクションのみが送信されるため、数百MB（GB）の単一トランザクションが送信されると、レプリケーション・エージェントの処理速度が低下する可能性があります。TimesTenのレプリケーションは、多数の小さなトランザクション用に最適化されているので、単一のトランザクションで数百万もの行を削除するとパフォーマンスが低下します。

TRUNCATE TABLEの優先

表のすべての行を削除するよりも、TRUNCATE TABLE文を使用することを検討してください。この文には、WHERE句のないDELETE文と最終的に同じ効果があり、ログが大幅に少なくなります。さらにレプリケーションを使用すると、TRUNCATE操作は、削除した行ごとに1つの操作となるのではなく、1つの操作として他のデータ・ストアにレプリケートされます。

DELETE FIRST句の検討

数多くの行を削除する必要があり、TRUNCATEが適切でない場合は、DELETE FIRST NumRows句を使用して、バッチで表から行を削除することを検討してください。DELETE FIRST NumRowsの構文を使用すると、DELETE FROM TableName WHERE ...をDELETE FIRST 10000 FROM TableName WHERE ...操作のシーケンスに変更できます。

大規模な削除操作をより小さな操作のバッチに分割すると、行の削除がより高速になり、システム全体の同時実行性およびレプリケーションへの影響がなくなります。

必要以上に長いトランザクションの短縮

「デッドロックおよびロック・タイムアウト・エラーの処理」で説明するとおり、実行時間の長いトランザクションによって他のデータ・ストア操作がロック・タイムアウト・エラーで失敗する場合があります。実行時間の長いトランザクションでは、通常、リソースが長時間ロックされたままになるため、システム全体の同時実行性が低下します。したがって、実行時間の長いトランザクションは、システム全体の安定性とシステム全体のパフォーマンスの両方を低下させるおそれがあります。

XLA応答モードの効果的な使用

XLAの応答メカニズムは、アプリケーションがメッセージを受信するだけでなく、メッセージを正常に処理できるように設計されています。永続的に更新に応答すると、アプリケーションのXLAブックマークは、読み取られた最終レコードにリセットされます。これにより、以前に返されたレコードが再度読み取られることを回避できます。また、アプリケーションがXLAに再接続したときにブックマークが再利用された場合、以前に応答されたレコードをアプリケーションが受信しないようにすることもできます。

JMS/XLAは、XLA更新メッセージに自動的に応答します。また、アプリケーションは、応答するメッセージを明示的に選択できます。Sessionを作成したときに、更新の応答方法を指定します。JMS/XLAでは、次の3つの応答方法がサポートされています。

AUTO_ACKNOWLEDGE: 更新が受信されると自動的にその更新が確認されます。各メッセージは1回だけ配信されます。AUTO_ACKNOWLEDGEモードでは、JMS/XLAは複数のレコードをプリフェッチしません（トピック内のxlaprefetch属性は無視されます）。

DUPS_OK_ACKNOWLEDGE: 更新は自動的に確認されますが、アプリケーションに障害が発生すると、重複するメッセージが配信されることがあります。JMS/XLAはトピックに対して指定されているxlaprefetch属性に基づいてレコードをプリフェッチし、プリフェッチされたブロック内の最終レコードが読み取られると応答を送信します。プリフェッチされたすべてのレコードを読み取る前にアプリケーションに障害が発生すると、ブロック内のすべてのレコードは、アプリケーションの再起動時にアプリケーションに渡されます。

CLIENT_ACKNOWLEDGE: アプリケーションはMapMessageへの応答をコールすることによって更新メッセージの受信を確認します。JMS/XLAはトピックに指定されているxlaprefetch属性に基づいてレコードをプリフェッチします。

更新のプリフェッチ

複数の更新レコードを一度にプリフェッチする処理は、XLAから各更新レコードを個々に取得する処理より効率的です。可能な場合は、更新の複製を許可するようにアプリケーションを設計します。これによって、DUPS_OK_ACKNOWLEDGEの使用、または更新の明示的な確認が可能になります。

更新の確認

XLA更新を明示的に確認するには、更新メッセージに対する確認をコールしてください。メッセージを暗黙的に確認すると、以前のすべてのメッセージが確認されます。CLIENT_ACKNOWLEDGEモードを使用していて、永続サブスクリプションを将来再利用する場合は、終了する前に、確認をコールして最後に読み取られた位置にブックマークを再設定する必要があります。